The cam registers as a composite device. There are two interfaces: The irst one has the standard control pipe and an isochronous IN pipe. This interface is probably used for live camera applications. The second interface has the standard control pipe, a bulk in pipe (for reading data from the cam), a bulk out pipe (for sending data to the cam - I don't know if this is supported with the Aiptek firmware) and an interrupt pipe (for camera events - can we read the button?).
The remainder of this text is just about the second interface. For downloading images, only the control pipe and the bulk in pipe are used.
There seem to be registers that can be read and set. The chip register base address seems to be 0x2000. The registers seem to be similar to those of the SPCA500A (except that their base address is 0x8000)
Write register
--------------
Control request (vendor,interface,out) req:0x00 value:0x00aa index:0xbbbb len=0 (aa=value, bbbb=register address)
Read register
-------------
Control reauest (vendor,interface,out) req:0x00 value:0x0000 index:0xbbbb len=1 (bbbb=register address) -> returns value
According to the SPCA500A specs, register blocks are:
0x2000 - 0x20ff : global control registers
0x2100 - 0x21ff : CDSP (image processing) control registers
0x2200 - 0x22ff : TG (timing generator) control registers
0x2300 - 0x23ff : Post buffer (transfer memory) control registers
0x2400 - 0x24ff : Flash memory control registers
0x2500 - 0x25ff : USB control registers
0x2600 - 0x26ff : Audio control registers
0x2700 - 0x27ff : DRAM control registers
0x2800 - 0x28ff : JPEG control registers
0x2900 - 0x29ff : CPU control registers
0x2a00 - 0x2aff : Synchronous control registers
0x3000 - 0x9fff?: Internal SRAM test registers / Test mode (???)
The win driver accesses the following banks:
global: 0x2000 is set to 0x00 at the very start
post buffer: 0x2301 is set to 0x13 on start. 0x2306 is set to 0x00 (not directly) before and to 0x01 after the image data transfer
USB control: 0x2501 is set to 0x01 once (not directly) before the data transfer.
JPEG control: The banks from 0x2800 to 0x283f and 0x2840 to 0x287f are set (interleavedly) - this would match setting of the Y and C quantization matrices
There seem to be more sensible commands than getting and setting registers (although they have a request code other than 0x00).
in : req 0x0b val 0x0000 idx 0x0005 len 1 Same as "Get Thumbnail"
in : req 0x01 val 0x0040 idx 0x0005 len 1 Same as "Get Thumbnail"
out: req 0x0a val 0x00zz idx 0x000d Request bulk read of image zz
in : req 0x0b val 0x0000 idx 0x0004 len 1 Same as "Get TOC"
Bulk read (in blocks of 256 bytes). You can get the JPEG file length from the TOC entry. However, the camera tends to send more data than necessary. If you don't read all sent data, you are in trouble because you will get junk in the next bulk read. I don't know how the win driver finds out the exact amount to read (it seems to know that). I currently issue the read commands with a timeout of 0.3 seconds - if they time out, the pipe is clear.
The device seems to be a bit timing sensitive. Sometimes, you cannot issue the commands too fast. I.E. wait-for-ready loops had to be slowed down in my experiments in order not to crash the firmware. I added a sleep(1) into the two waiting
